Skip to content

Bump JasperFx.Events.SourceGenerator from 2.36.3 to 2.39.5 - #27

Closed
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/nuget/JasperFx.Events.SourceGenerator-2.39.5
Closed

Bump JasperFx.Events.SourceGenerator from 2.36.3 to 2.39.5#27
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/nuget/JasperFx.Events.SourceGenerator-2.39.5

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 5, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Updated JasperFx.Events.SourceGenerator from 2.36.3 to 2.39.5.

Release notes

Sourced from JasperFx.Events.SourceGenerator's releases.

2.39.5

What's Changed

Full Changelog: JasperFx/jasperfx@V2.39.3...V2.39.5

2.39.3

What's Changed

Full Changelog: JasperFx/jasperfx@V2.39.1...V2.39.3

2.39.1

A single fix on top of 2.39.0.

EventProjection teardown (#​626)

JasperFxEventProjectionBase's constructor never touched Options, so an EventProjection registered no teardown targets — Options.CleanUps and Options.StorageTypes stayed empty unless the author hand-called Options.DeleteViewTypeOnTeardown<T>(). Aggregation projections have always registered their single TDoc, and nothing in the API surface signalled the difference.

Everything that derives "what does this projection own" from those lists silently did nothing for event projections: a rebuild deleted the progression row and then re-projected into a table still holding the previous run's documents, per-tenant progression deletion left the documents behind, and the ProjectionScenario harness wipe never wiped after an event projection.

Published types are now registered as teardown targets in AssembleAndAssertValidity() rather than the constructor — the source generator emits its RegisterPublishedType calls into the subclass constructor, which runs after the base one, so only assembly time sees the complete set. Registration is idempotent.

Behavior change

Rebuilding an event projection now truncates the document types it publishes. That is the point of the fix, but if a projection writes into storage it doesn't own — an append-only audit table, or documents another projection owns — set the new opt-out:

public class MyProjection : EventProjection
{
    public MyProjection()
    {
        DeletePublishedTypesOnTeardown = false;
    }
}

It is all-or-nothing: turn it off and call Options.DeleteViewTypeOnTeardown<T>() for the types you do want wiped.

Because DeleteViewTypeOnTeardown writes to both CleanUps and StorageTypes, the ProjectionScenario test-harness wipe also starts working after event projections. Desirable, and now deliberate rather than incidental.

What's Changed

Full Changelog: JasperFx/jasperfx@V2.39.0...V2.39.1

2.39.0

Projection lag, per-tenant high-water parsing, and a large cut in the async daemon's idle database traffic.

Highlights

A supported per-tenant projection lag read (#​619, #​627). "How far behind is projection X, at its current version, for tenant T on this database?" had no supported answer, so the correlation had been reinvented three times — the daemon's blue/green side-effect gate, Marten's WaitForNonStaleDataAsync, and application code in the field — each rediscovering the same traps. ProjectionLag + ProjectionLagCalculator + IEventDatabase.FetchProjectionLagAsync / IEventStore<,>.FetchProjectionLagAsync now express it once, anchored on registered sources at their current version, over the single AllProjectionProgress round trip that already exists. No new SQL, and every store gets it through a default interface implementation. A registered cell with no row reads as fully behind, not caught up.

Per-tenant HighWaterMark:{tenant} rows round-trip through ShardName (#​618, #​623). ShardName.TryParse("HighWaterMark:acme", ...) used to return true and a wrong answer — the tenant id in the shard-key slot, TenantId null, and an Identity that didn't match the input. Those rows are real and persisted (Marten writes one per tenant on every vectorized high-water poll), so any consumer grouping progression rows by tenant silently attributed every tenant's mark to the store-global one. ShardName.HighWaterMarkFor(tenantId) and ShardName.IsHighWaterMark are the supported way to compose and recognize them.

Only a daemon that actually runs agents writes extended progression telemetry (#​621, #​625). The ShardStateTracker is per-database and shared, and every JasperFxAsyncDaemon subscribed an ExtendedProgressionWriter to it in the constructor — including daemons built ad hoc purely to read state, which is a documented thing to do. N daemons for one database meant N writers on one publication stream, each renting a connection and issuing the same UPDATE against the same rows. The subscription is now armed on the start path and released on stop; an unstarted daemon writes nothing at all.

The periodic per-shard heartbeat is off by default (#​622, #​628). It cost one pooled connection and one transaction per database per node every 5 seconds — ~37 connection acquisitions/sec/node on a 512-shard-database deployment — and an audit across JasperFx, Marten and CritterWatch found nothing that reads the persisted value. Agent status transitions are still written, which is what the extended columns are actually for. The cadence is now reachable from application code for the first time via DaemonSettings.ExtendedProgressionHeartbeatInterval; a positive value restores the old behavior as a compatibility hatch.

Upgrade notes

  • Per-tenant high-water ShardNames are now distinct values where they previously all compared equal to the store-global mark. That collapse was the bug; nothing in JasperFx constructed such a name.
  • TryParse now rejects HighWaterMark-prefixed strings other than the bare constant and HighWaterMark:{tenant}, instead of forcing them into the generic grammar.
  • If you depend on the persisted 5-second heartbeat, set DaemonSettings.ExtendedProgressionHeartbeatInterval. Nothing in the Critter Stack reads it today.

What's Changed

Full Changelog: JasperFx/jasperfx@V2.38.0...V2.39.0

2.38.0

What's Changed

Full Changelog: JasperFx/jasperfx@V2.37.0...V2.38.0

2.37.0

What's Changed

Full Changelog: JasperFx/jasperfx@V2.36.1...V2.37.0

Commits viewable in compare view.

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

@dependabot
Bump JasperFx.Events.SourceGenerator from 2.36.3 to 2.39.5
d8b7c40 
---
updated-dependencies:
- dependency-name: JasperFx.Events.SourceGenerator
  dependency-version: 2.39.5
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added .NET Pull requests that update .NET code dependencies Pull requests that update a dependency file labels Aug 5, 2026
@dependabot dependabot Bot mentioned this pull request Aug 5, 2026
Closed
@dependabot @github

dependabot Bot commented on behalf of github Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

Looks like JasperFx.Events.SourceGenerator is no longer updatable, so this is no longer needed.

@dependabot dependabot Bot closed this Aug 5, 2026
@dependabot
dependabot Bot deleted the dependabot/nuget/JasperFx.Events.SourceGenerator-2.39.5 branch August 5, 2026 18:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file .NET Pull requests that update .NET code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants